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REMARKS 

The above-identified application is United States application serial number 
10/056,145 filed on January 22, 2002. Claims 1-22 are pending in the application. Claims 1- 
22 are rejected under 35 U.S.C § 102(e) as being anticipated by Holenstein et al (USP 
Application 2002/0133507 Al) (hereafter Holenstein). Applicant respectfully traverses this 
rejection. 

Claim Objections 

Claim 1 8 is objected to because in line 20, page 3 1, the acronym name "TMF" is not 
defined in the claim. In response, Applicant has amended Claim 18 to include the phrase 
"Transaction Management Facility", which is represented by the acronym TMF. 

Claim Rejections - 35 U.S.C § 102 

Claim 1 sets forth " committing the first transaction before initiating a lockstep 
transaction that updates a second file in the primary computer system". This feature is 
supported by at least page 12 lines 20-29 and page 13 lines 1 1-25 of the specification. 
Holenstein, in contrast, does not commit the transaction until after the originating node 
knows that all of the other nodes in the system have locked the appropriate rows, performed 
the transaction, and are ready to commit the transaction, (Holenstein U 01 02 and ^ 0105). 
Claim 1 is thus distinguishable from Holenstein for at least these reasons. 

Claims 2-4 depend from Claim 1 and include features that further distinguish them 
from the cited reference. In particular, Claim 2 sets forth "the lockstep transaction is initiated 
by a procedure call made immediately upon completion of the first transaction". In contrast, 
Holenstein teaches pausing the transaction before initiating the ready to commit process, and 
completing the transaction only when all nodes are ready to commit the transaction. 
(Holenstein 1 0123). 

Claim 4 recites "after the second lockstep transaction is initiated, ignoring said 
confirmation that the audit records representing the updates to the first file by the first 
transaction and the updates to the second file by the lockstep transaction have been durably 
stored by the backup computer system". In contrast, Holenstein does not teach or suggest 
ignoring said confirmation. Holenstein teaches pausing the transaction before initiating the 
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ready to commit process, and completing the transaction only when all nodes are ready to 
commit the transaction. (Holenstein 0123). Holenstein must check all confirmations 
because the primary processor only commits a transaction when all nodes are ready to 
commit the transaction, and therefore never ignores the confirmation. 

Allowance of Claims 1-4 is respectfully requested. 

Claim 5 recites 

therein the backup computer system includes mechanism for safely storing 
the lockstep audit record and audit records preceding the lockstep audit 
record immediately upon receiving the lockstep audit record, the 
backup computer system further including mechanisms for 
transmitting a safe auditrail position of the Lockstep audit record to the 
primary computer system after the Lockstep audit record is safely 
stored; 

receiving the safe auditrail position from the backup computer system; 

checking whether the safe auditrail position corresponds to a lockstep 
transaction that is currently active". 

In contrast Holenstein does not disclose or suggest these features in Claim 5. The portion of 
Holenstein cited (If 0134) as disclosing these features teaches stopping the transaction if the 
RTS tokens do not properly and/or timely return from the other nodes. Holenstein does not 
disclose or suggest "transmitting a safe auditrail position of the Lockstep audit record", or 
"checking whether the safe auditrail position corresponds to a lockstep transaction that is 
currently active". Claim 5 is thus distinguishable from Holenstein for at least these reasons. 

Claims 6-10 depend from Claim 5 and include features that further distinguish them 
from the cited reference. In particular, Claim 6 sets forth 

"during the reading step and upon encountering the first lockstep audit record, 

extracting an audit trail position and a transaction identifier from the 

first lockstep audit record; 
storing the extracted audit trail position at a second location of the pre-defined 

data structure; and 

storing the extracted transaction identifier at a third location of the pre-defined 
data structure". 

The audit trail position feature is supported on at least page 6 lines 1 1-17 and 26-32, page 10 
lines 12-15, page 12 lines 6-12, page 17 lines 1-30, page 19 lines 1-25, page 20 lines 34-35, 
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and page 21 lines 1-4 and 10-20 of the specification. There is no mention or suggestion of an 
audit trail position of a lockstep audit record or any of these other features of Claim 6 in 
Holenstein. Although paragraph 0134 in Holenstein is cited as disclosing these features, 
paragraph 0134 actually pertains to stopping the transaction if the RTS tokens do not properly 
and/or timely return from the other nodes. Hie tokens in Holenstein allow earlier detection of 
collision situations during replication, and to know whether certain parts of lengthy 
transactions have been safe-stored at all nodes. Such teachings do not pertain to the audit 
trail position of a lockstep audit record. Claim 6 is allowable over Holenstein for at least 
these reasons. 

Allowance of Claims 5-10 is respectfully requested. 

Claim 1 1 recites: 

"storing an audit trail position of the first update in the pre-defined data 

structure upon encountering the first lockstep audit record during the 
extracting step; 

storing the first unique transaction identifier in the pre-defined data structure 
as a lockstep audit transaction identifier (LockStep_Audit_TID) upon 
encountering the first lockstep audit record during the extracting step; 

. . . wherein the backup computer system is configured to transmit to the 
primary computer system a safe position indicating the audit trail 
position of durably stored audit records upon receiving the lock-step 
indicator; 

comparing the safe position returned by the backup computer system to the 
audit trail position stored in the pre-defined data structure; and 

indicating completion of the lockstep replication procedure when the safe 

position is equal to or higher than the audit trail position stored in the 
pre-defined data structure, and when the lockstep gateway transaction 
identifier (LockStep_Gateway_TID) matches the lockstep audit 
transaction identifier - (LockStep_Audit_TID)." 

There is no mention or suggestion of an audit trail position of a lockstep audit record or any 
of these other features of Claim 1 1 in Holenstein. Although paragraph 0134 in Holenstein is 
cited as disclosing these features, paragraph 0134 actually pertains to stopping the transaction 
if the RTS tokens do not properly and/or timely return from the other nodes. The tokens in 
Holenstein allow earlier detection of collision situations during replication, and to know 
whether certain parts of lengthy transactions have been safe-stored at all nodes. Such 
teachings do not pertain to the audit trail position of a lockstep audit recorcl. Claim 1 1 is 
allowable over Holenstein for at least these reasons. 

Additionally, Holenstein paragraphs 0221 and 0266 were cited as teaching features in 
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Claim 11. Applicant would like to point out, however, that the filing date of Holenstein 
US2002/0133507 is March 29, 2002, which is after the filing date of January 22, 2002 of the 
present application. Holenstein US2002/0 133507 is a continuation-in-part of U.S. Patent No. 
6,662,196, which was filed on March 16, 2001 . Accordingly, Holenstein 6,662,196 can be 
used as a reference against the present application along with paragraphs 0020 through 0143 
of Holenstein US2002/0 133507, which disclose substantially the same material. Paragraphs 
0144 through 0342 of Holenstein US2002/0 133507 were not filed until March 29, 2002, 
however, and therefore do not constitute prior art with respect to the present application. 

Claims 12-14 depend from Claim 1 1 and include features that further distinguish them 
from the cited reference. Allowance of Claims 1 1-14 is respectfully requested. 

Claim 1 5 sets forth: 

"wherein the backup computer system is configured to transmit to the 

extractor a safe position indicating the audit trail position of durably 
stored audit records upon receiving the lock-step indicator; 

the extractor configured to compare the safe position returned by the backup 
computer system to the audit trail position stored in the pre-defined 
data structure; 

the extractor configured to communicate to the gateway a status of the 

lockstep replication procedure when the safe position is equal to or 
higher than the audit trail position stored in the pre-defined data 
structure". 

Claim 18 sets forth: 

"the extractor configured to store an audit trail position of the first update in 

the pre-defined data structure upon encountering the first lockstep 

audit record in the audit trail; 
the extractor configured to compare the safe position returned by the backup 

computer system to the audit trail position stored in the pre-defined 

data structure; 

the extractor configured to communicate to the gateway a status of the 

lockstep replication procedure when the safe position is equal to or 
higher than the audit trail position stored in the pre-defined data 
structure, and when the lockstep gateway transaction identifier 
(LockStep_Gateway_TID) matches the lockstep audit transaction 
identifier (LockStep_Audit_TTD)'\ 

There is no mention or suggestion of an audit trail position of a lockstep audit record or any 
of these other features of Claims 15 and 18 in Holenstein. Although paragraph 0134 in 
Holenstein is cited as disclosing these features, paragraph 0134 pertains to stopping the 
transaction if the RTS tokens do not properly and/or timely return from the other nodes. The 



14 of 15 10/056,145 

PAGE 16/17 * RCVD AT 8/912004 6:28:37 PM [Eastern Daylight Time] * SVR:USPTO£FXRM/0 " DNlS:8729306 * CSID:M9251 0260 1 DURATION (mm-ss):05-32 



08/09/2004 15:36 FAX 9432510260 



KOESTNER_BERTANI_LLP 



0017/01 



tokens in Holenstein allow earlier detection of collision situations during replication, and to 
know whether certain parts of lengthy transactions have been safe-stored at all nodes. Such 
teachings do not pertain to the audit trail position of a lockstep audit record. Claims 1 5 and 
18 are allowable over Holenstein for at least these reasons. 

Claims 16-17 and 19-22 depend from Claims 15 and 18, respectively, and include 
features that further distinguish them from the cited reference. Allowance of Claims 1 5-22 is 
respectfully requested. 



Claims 23 and 24 have been added to capture subject matter originally disclosed at 
least on page 7, lines 1-8 of the specification. Claims 23 and 24 depend from Claim 18 and 
include features that further distinguish them from the cited reference. Allowance of Claims 
23-24 is respectfully requested. 



In view of the amendments and remarks set forth herein, Applicant believes Claims 1- 
24 are in form for allowance and a notice to that effect is solicited. In the event it would 
facilitate prosecution of this application, the Examiner is invited to telephone the undersigned 
at (949) 251-0250. 



New Claims 



CONCLUSION 
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Respectfully submitted* 



MaivJn Bmani 

(Printed Name at Person Signing Certificate) 




Attorney for Applicant(s) 
Reg. No. 42,321 
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